- AseParserByJhs . . . . 19 matches
// a triangle in the model
// texture information for the model
static void ModelAlloc (CHS_GObject* pO); // 쓰이지 않음. j_ase 모듈에 있는 aseAllocate2CHS_Model을 사용
static void ReleaseModels (); // s_AllList상의 모든 노드를 삭제한다.
pNodeList [0]->bIsSkinModel = TRUE;
//pNodeList [i]->ModelAlloc ();
aseAllocate2CHS_Model (pNodeList [i]);
CHS_Model** pChildTmp = pNodeList [i2]->GetChildPointer (); // 임시 보관
CHS_Model** pDest = new CHS_Model* [pNodeList [i2]->GetChildNum ()]; // 새 메모리 할당
memcpy (pDest, pChildTmp, sizeof (CHS_Model*) * (pNodeList [i2]->GetChildNum ()-1)); // 복사
CHS_Model* pTmp = pNodeList[i];
void CHS_GObject::ReleaseModels ()
CHS_Model* pM;
pM = new CHS_Model;
//pLink->AddTail(pModel);
void CHS_GObject::ModelAlloc (CHS_GObject* pO)
CHS_Model* pM = 0;
// pM = (CHS_Model*)*itor;
//pM = (CHS_Model*)*itor;
- ZIM/EssentialUseCase . . . . 12 matches
=== actors ===
* Actor : Zimmer
|| Actor Action || System Response ||
* Actor : Zimmer
|| Actor Action || System Response ||
* Actor : Zimmer
|| Actor Action || System Response ||
* Actor : Zimmer
|| Actor Action || System Response ||
* Actor : Zimmer
|| Actor Action || System Response ||
* Actor : Zimmer
|| Actor Action || System Response ||
- CMM . . . . 8 matches
Capability Maturity Model. 미국 Software 평가모델의 표준. ISO 표준으로는 ["SPICE"] 가 있다.
* SW-CMM : Capability Maturity Model for Software. 소프트웨어 프로세스의 성숙도를 측정하고 프로세스 개선 계획을 수립하기 위한 모델
* P-CMM : People Capability Maturity Model. 점차적으로 복잡해지는 소프트웨어 환경에 효과적으로 대응하기 위하여 개인의 능력을 개발하고 동기부여를 강화하며 조직화하는 수준을 측정하고 개선하기 위한 모델
* SA-CMM : Software Acquisition Capability Maturity Model. 소프트웨어 획득 과정을 중점적인 대상으로 하여 성숙도를 측정하고 개선하기 위한 모델
* SE-CMM : Systems Engineering Capability Maturity Model. 시스템공학 분야에서 적용하여야 할 기본 요소들을 대상으로 현재의 프로세스 수준을 측정하고 평가하기 위한 모델로서 기본적인 프레임웍은 SW-CMM과 유사
* IPD-CMM : Integrated Product Development Capability Maturity Model. 고객 요구를 보다 잘 충족시키기 위하여 소프트웨어 제품의 생명주기 동안에 각각 진행되는 프로젝트들이 적시에 협동할 수 있는 제품 개발체계를 도입하기 위한 모델
* CMMI : Capability Maturity Model Integration. 모델을 사용하는 입장에서는 각각의 모델을 별개로 적용하는 것보다는 전체적 관점에서 시너지 효과를 내기 위해서는 어떻게 적용할 것인가에 대한 방안이 필요하게 되어 개발된 통합 모델
* wiki:Moa:CapabilityMaturityModel
- TwistingTheTriad . . . . 8 matches
ModelViewPresenter 관련 Article 읽고 정리.
One example of this deficiency surfaced in SmalltalkWorkspace widget. This was originally designed as a multiline text-editing component with additional logic to handle user interface commands such as Do-it, Show-it, Inspect-it etc. The view itself was a standard Windows text control and we just attached code to it to handle the workspace functionality. However, we soon discovered that we also wanted to have a rich text workspace widget too. Typically the implementation of this would have required the duplication of the workspace logic from the SmalltalkWorkspace component or, at least, an unwarranted refactoring session. It seemed to us that the widget framework could well do with some refactoring itself!
=== ModelViewController ===
In MVC, most of the application functionality must be built into a model class known as an Application Model. It is the reponsibility of the application model to be the mediator between the true domain objects and the views and their controllers. The views are responsible for displaying the domain data while the controller handle the raw usr gestures that will eventually perform action on this data. So the application model typically has method to perform menu command actions, push buttons actions and general validation on the data that it manages. Nearly all of the application logic will reside in the application model classes. However, because the application model's role is that of a go-between, it is at times necessary for it to gain access to the user interface directly but, because of the Observer relationship betweeen it and the view/controller, this sort of access is discouraged.
For example, let's say one wants to explicitly change the colour of one or more views dependent on some conditions in the application model. The correct way to do this in MVC would be to trigger some sort of event, passing the colour along with it. Behaviour would then have to be coded in the view to "hang off" this event and to apply the colour change whenever the event was triggered. This is a rather circuitous route to achieving this simple functionality and typically it would be avoided by taking a shoutcut and using #componentAt : to look up a particular named view from the application model and to apply the colour change to the view directly. However, any direct access of a view like this breaks the MVC dictum that the model should know nothing about the views to which it is connected. If nothing else, this sort of activity surely breaks the possibility of allowing multiple views onto a model, which must be the reason behind using the Observer pattern in MVC in the first place.
- 내가 파악한 MVC 모델은 너무 얕은 지식이였나. 여태껏 그냥 Layer 단으로만 그렇게 나누어진다만 생각했지 해당 이벤트 발생시나 모델의 값 변화시 어떠한 단계로 Control 이 흘러가는지에 대해서는 구체적으로 생각해본 적이 없었던 것 같다. 화살표를 보면 Application Model -> Controller 로의 화살표가 없다. 그리고 Problem Space 의 범위도 차이가 난다.
근데, WEB 에서의 MVC 와 GUI 에서의 MVC 는 그 Control Flow 가 다르긴 할것이다. 웹에서는 View 부분에서 이벤트가 발생하여 이것이 도로 Model 로 올라간다..식이 없기 때문이다. 믿을만한 출처일지는 모르겠지만, 암튼 이를 구분하는 글도 있는듯. http://www.purpletech.com/articles/mvc/mvc-and-beyond.html
=== TwistingTheTriad : ModelViewPresenter ===
Model
This is the data upon which the user interface will operate. It is typically a domain object and the intention is that such objects should have no knowledge of the user interface. Here the M in MVP differs from the M in MVC. As mentioned above, the latter is actually an Application Model, which holds onto aspects of the domain data but also implements the user interface to manupulate it. In MVP, the model is purely a domain object and there is no expectation of (or link to) the user interface at all.
The behaviour of a view in MVP is much the same as in MVC. It is the view's responsibility to display the contents of a model. The model is expected to trigger appropriate change notification whenever its data is modified and these allow the view to "hang off" the model following the standard Observer pattern. In the same way as MVC does, this allows multiple vies to be connected to a single model.
One significant difference in MVP is the removal of the controller. Instead, the view is expected to handle the raw user interface events generated by the operating system (in Windows these come in as WM_xxxx messages) and this way of working fits more naturally into the style of most modern operating systems. In some cases, as a TextView, the user input is handled directly by the view and used to make changes to the model data. However, in most cases the user input events are actually routed via the presenter and it is this which becomes responsible for how the model gets changed.
While it is the view's responsibility to display model data it is the presenter that governs how the model can be manipulated and changed by the user interface. This is where the heart of an application's behaviour resides. In many ways, a MVP presenter is equivalent to the application model in MVC; most of the code dealing with how a user interface works is built into a presenter class. The main difference is that a presenter is ''directly'' linked to its associated view so that the two can closely collaborate in their roles of supplying the user interface for a particular model.
- django/Model . . . . 8 matches
class Risk(models.Model):
#id = models.AutoField()
name= models.CharField(maxlength=10)
class RiskReport(models.Model):
risk= models.ForeignKey(Risk)
class RiskReport(models.Model):
risk= models.ForeignKey('Risk')
class Employee(models.Model):
name= models.CharField(maxlength=100)
email= models.EmailField()
class Department(models.Model):
name= models.CharField(maxlength=100)
location= models.CharField(maxlength=200)
employees= models.ManyToManyField(Employee)
class RiskReport(models.Model):
class ControlReport(models.Model):
class RiskControl(models.Model):
risk_report= models.ForeignKey(RiskReport)
control_report= models.ForeignKey(ControlReport)
is_vaild= models.BooleanField()
- 객체지향분석설계 . . . . 8 matches
먼저 Actor를 선정한다. Actor를 잘 선택하면 추후에 유즈케이스를 구분할 때에 도움이 된다.
* 한 사람(Actor)이 한 순간에 한 장소에서 수행할 수 있는 업무인가.
* 관련 Actor : 이 유즈케이스에 참여하는 Actor
기본흐름, 대안흐름, 예외흐름은 Actor로부터 시작하는 것이 원칙이다. Actor로부터 시작하여 일어나는 일을 정리한다.
위의 분석을 바탕으로 하여 Sequence Diagram을 개략적으로 작성한다. 역시 Actor와 각 클래스들을 미리 배치한 다음 필요한 조작들을분석한다.
- ModelViewPresenter . . . . 7 matches
http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm
Wiki:ModelViewPresenter
|| Model ||
MVC 에서 유래. MVP 의 목적은 Model 과 View 사이의 Observer connection 에 대해 더 깔끔한 구현을 제공하는 것이다.
* Model - domain data
* Selection - Model 의 서브셋을 구체화한다. (Command에 의해 조정된다.)
* Interactor - 키보드나 마우스 이벤트들을 Command 나 Selection 으로 매핑한다.
Model-View-Presenter or MVP is a next generation programming model for the C++ and Java programming languages. MVP is based on a generalization of the classic MVC programming model of Smalltalk and provides a powerful yet easy to understand design methodology for a broad range of application and component development tasks. The framework-based implementation of these concepts adds great value to developer programs that employ MVP. MVP also is adaptable across multiple client/server and multi-tier application architectures. MVP will enable IBM to deliver a unified conceptual programming model across all its major object-oriented language environments.
- ProjectZephyrus/ClientJourney . . . . 4 matches
* 일이 거의 막마지에 다다른다. 12시 이후 본격적 작업. 이틀간의 스케줄에서 둘이 참여를 하지 않았으므로, 작업은 주로 코드 설명이 주가 될 수 밖에 없었다. Pair로 ["Refactoring"] 해나가며 설명하기에 내가 너무 많이 코드를 고쳤나. -_-; (나도 할말있는것이, 가장 중요사항중 하나인 패킷 핸들러 처리부분할때 다들빠지냐는것이다. -_-; 제일 얻을 것도 많은 부분일건데 쩝. 개인적으로 만들면서 흐뭇(^^;) 했던 부분이고;)
* TDD 가 아니였다는 점은 추후 모듈간 Interface 를 결정할때 골치가 아파진다. 중간코드에 적용하기 뭐해서 궁여지책으로 Main 함수를 hard coding 한뒤 ["Refactoring"] 을 하는 스타일로 하긴 하지만, TDD 만큼 Interface가 깔끔하게 나오질 않는다고 생각. 차라리 조금씩이라도 UnitTest 코드를 붙이는게 나을것 같긴 하다. 하지만, 마감이 2일인 관계로. -_- 스펙 완료뒤 고려하던지, 아니면 처음부터 TDD를 염두해두고 하던지. 중요한건 모듈자체보다 모듈을 이용하는 Client 의 관점이다.
''순수한 형태의 MVC 모델을 구경해본적이 없는 관계로;; 저에겐 추상적인 개념일 뿐인지라. 하긴 JTree 에서 TreeModel 부분과 TreeRender & UIManager 부분, JTree 부분에 연결된 리스너와 관련할때 정확히 Control 부분과 UI 부분이 따로 떨어지지 않고 경계가 좀 모호하긴 하다는. --석천''
Client 팀은 일단 메신저와 관련한 자신들의 디자인을 설명해보는 시간을 가졌다. 사람들은 프로그래밍을 하기 전에 어떤 스타일로 구상을 하게 될까. Agile Modeling 에서 봤던가. 모델 보다는 모델링이 중요하다고 했었던 이야기. 모델링을 해 나가면서 자신의 생각을 정리하고, 프로그램을 이해해 나가는 것이 중요하기에.[[BR]]
1002의 경우 UML을 공부한 관계로, 좀 더 구조적으로 서술 할 수 있었던 것 같다. 설명을 위해 Conceptual Model 수준의 Class Diagram 과 Sequence, 그리고 거기에 Agile Modeling 에서 잠깐 봤었던 UI 에 따른 페이지 전환 관계에 대한 그림을 하나 더 그려서 설명했다. 하나의 프로그램에 대해 여러 각도에서 바라보는 것이 프로그램을 이해하는데 더 편했던 것 같다. [[BR]]
- SibichiSeminar/TrustModel . . . . 4 matches
* 연구실에서 Trust Model에 대한 일을 하고있어서.
1. TrustModel에 대한 것과 별개로 프리젠테이션 한 것도 정말 중요한 내용이라 오늘 온 새내기분들이 잘 기억하고 계셨으면 좋겠습니다. 버전 관리의 필요성이나 유용함에 대해서는 직접 느껴봐야 와닿을거예요. ZeroPage에서 느낄 수 있는 기회를 마련하도록 하겠습니다. - [김수경]
* 세미나를 보면서, 와.. 저런걸 여기서(우리 코앞에 있는 연구실)도 구현하는구나.. 라는 생각이 들어서 뭐랄까, 진짜로 뭔가 연구하는데 다가간다는 느낌이 들었네요. TrustModel과 비슷한걸 만들고자 하는 사람들을 아는데, 저런식으로 아예 수치화 시키는게 역시 효율적인가.. 라는 생각도 들었구요, 후에 연구실(다른데인가?)에 들어간다면 저런걸 하는걸 보게/혹은 후에는 직접 하게될 수 있다는 사실에 나름 다시 감탄(?)했어요. ..아, 개발자와 기획자가 상상하는 것에서 상당히 그럴듯하다고 생각했어요.(창설에 이렇게 만들어달라고 하면 상당히 다른 모양이 탄생하곤 했지요) -[김태진]
* 세미나 주제가 참 놀라웠습니다. 페이스북을 이용해 관심사가 같은 사람들을 엮어주는 앱은 이미 나와있지만, 이건 일일히 사용자가 입력을 해야하는데, TrustModel은 프로그램이 알아서 다해주는것 같더군요. 지식이 얇아서 여기까지밖에 이해 못했습니다. 꺼이꺼이. 세미나 막간에 넣은 M-16인용 개발자-기획자-디자이너의... 뭐라고 해야하나요. 암튼 재밌게 잘 봤습니다. 삼위일체가 답이군요. 하하하하.. 정확한 커뮤니케이션은 정말 힘든것 같아요. 새내기 다운 새내기가 없다는 말씀을 자꾸 하셨는데.. 저 새내기 맞아요 ㅜㅠ C언어도 학교 오고나서야 처음으로 알았어요 ㅜㅠ - [고한종]
- UDK/2012년스터디 . . . . 4 matches
// called when actor collided with wall physically.
event HitWall(Vector HitNormal, Actor Wall, PrimitiveComponent WallComp)
event bool NotifyHitWall(vector HitNormal, actor Wall)
event NotifyFallingHitWall(vector HitNormal, actor Wall);
// called when actor landed at FloorActor
event Landed(vector HitNormal, Actor FloorActor);
- UML . . . . 4 matches
== Unified Modeling Language(UML) ==
In software engineering, Unified Modeling Language (UML) is a non-proprietary, third generation modeling and specification language. However, the use of UML is not restricted to model software. It can be used for modeling hardware (engineering systems) and is commonly used for business process modeling, organizational structure, and systems engineering modeling. The UML is an open method used to specify, visualize, construct, and document the artifacts of an object-oriented software-intensive system under development. The UML represents a compilation of best engineering practices which have proven to be successful in modeling large, complex systems, especially at the architectural level.
This diagram describes the functionality of the (simple) Restaurant System. The Food Critic actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef Actor can Cook Food. Use Cases are represented by ovals and the Actors are represented by stick figures. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.
This diagram describes the sequences of messages of the (simple) Restaurant System. This diagram represents a Patron ordering food and wine; drinking wine then eating the food; finally paying for the food. The dotted lines extending downwards indicate the timeline. The arrows represent messages (stimuli) from an actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method calls.
A Collaboration diagram models the interactions between objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from [[#UML_Class Diagram|Class]], [[#UML_Sequence_Diagram|Sequence]], and [[#UML_Use_Case_Diagram|Use Case Diagrams]] describing both the static structure and dynamic behavior of a system.
Deployment diagrams serve to model the hardware used in system implementations and the associations between those components. The elements used in deployment diagrams are nodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations.
Although UML is a widely recognized and used standard, it is criticized for having imprecise semantics, which causes its interpretation to be subjective and therefore difficult for the formal test phase. This means that when using UML, users should provide some form of explanation of their models.
Another problem is that UML doesn't apply well to distributed systems. In such systems, factors such as serialization, message passing and persistence are of great importance. UML lacks the ability to specify such things. For example, it is not possible to specify using UML that an object "lives" in a [[server]] process and that it is shared among various instances of a running [[process]].
At the same time, UML is often considered to have become too bloated, and fine-grained in many aspects. Details which are best captured in source code are attempted to be captured using UML notation. The [[80-20 rule]] can be safely applied to UML: a small part of UML is adequate for most of the modeling needs, while many aspects of UML cater to some specialized or esoteric usages.
(However, the comprehensive scope of UML 2.0 is appropriate for [[model-driven architecture]].)
- UML서적관련추천 . . . . 4 matches
UML Distilled: A Brief Guide to the Standard Object Modeling Language,3rd Edition
The Unified Modeling Language User Guide 2/E
The Unified Modeling Language Reference Manual (2/E)
참고로 UML 은 'Modeling Language' 입니다. 모델링 서술을 위한 언어일 뿐, 모델링이나 디자인 방법 자체에 대한 설명을 하진 않습니다. 디자인 관련 서적은 따로 서술하겠습니다.
- 졸업논문/본론 . . . . 4 matches
[django/Model]
기본적으로 지원 되는 레코드 삽입, 삭제, 변경은 자동으로 사용자 화면까지 만들어주는 장점을 가진다. 대부분 웹 애플리케이션이 레코드를 한 건씩 입력하는 인터페이스를 가지기 때문에, 개발 전반부에 걸친 데이터 삽입, 삭제, 변경을 자동화할수 있기 때문이다. 특히 삽입, 변경은 저장이란 단일 개념으로 보고 save메소드로 추상화하였다. 또한 삭제는 관련된 레코드를 함께 지워주는 기능까지 제공한다. 이러한 기능은 Model클래스에 정의된 데이터 타입에 따라 자동으로 이루어진다. 따라서 삽입, 삭제, 변경 SQL문을 실행하는 인터페이스에 많은 노력을 기울이지 않고 기민하게 전체 시스템을 설계함에 집중할 수 있다.
레코드를 검색할 때는 기본적으로 간단한 질의를 처리할 수 있는 함수들을 제공한다. 앞서 살펴본 바와 같이 직접 관계를 가지는 테이블 사이에 조인 연산은 Model클래스의 메소드를 이용해서 추상화되어 있다. 하지만 그 밖인 경우에는 직접 SQL문을 작성하여 데이터를 얻어와야 하기 때문에 django를 사용하더라도 큰 이점이 없다. 또한 추상화된 Model클래스의 메소드는 기본적으로 모든 레코드 속성을 읽어오기 때문에 시간, 공간 측면에서 비효율적일 수 있다. 마지막으로 SQL의 aggregate function등을 대부분 추상화하지 않았기 때문에, 이 역시 SQL문을 작성해야 하는 번거로움이 있다.
- 3DGraphicsFoundation/INSU/SolarSystem . . . . 3 matches
// Modelview matrix reset
glMatrixMode(GL_MODELVIEW);
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, whiteLight);
glShadeModel(GL_SMOOTH);
glMatrixMode(GL_MODELVIEW);
- Gof/Composite . . . . 3 matches
CompositePattern의 예는 거의 모든 객체지향 시스템에서 찾을 수 있다. Smalltalk 의 Model/View/Container [KP88] 의 original View 클래스는 Composite이며, ET++ (VObjects [WGM88]) 이나 InterViews (Styles [LCI+92], Graphics [VL88], Glyphs [CL90])등 거의 대부분의 유저 인터페이스 툴킷과 프레임워크가 해당 과정을 따른다. Model/View/Controller 의 original View에서 주목할만한 점은 subview 의 집합을 가진다는 것이다. 다시 말하면, View는 Component class 이자 Composite class 이다. Smalltalk-80 의 Release 4.0 은 View 와 CompositeView 의 서브클래스를 가지는 VisualComponent 클래스로 Model/View/Controller 를 변경했다.
- ProjectPrometheus/Journey . . . . 3 matches
속좁은 ["1002"] 이 상민쓰에게 신경질 부리던날로 기억 -_-; 일종의 Test 에 대한 압박을 받아서이긴 한데, 처음에는 'Model, Logic' 부분에 대해서만 Test 정도 붙이면 되겠지 라고 생각했는데, Servlet 으로 작성한 Controller 부분이 커지면서, 각각 Command 에 해당하는 (service 라고 이름지었음) 부분에 대해 로직이 붙었기 때문이다. 근데, Servlet 이여서 테스트를 못붙이고, 작업은 작업대로 진행되는데 테스트 붙일 방법을 생각하지 못하는데, 잘 진행되어간다고 보이는 작업 발묶는것 같아서 이야기 못하고 꿍해있다는.
* Side Effect 는 Refactoring 의 적이라는 생각이 오늘처럼 든 적이 없었다. -_-; Extract Method 같은 일을 하는 경우 더더욱.! --["1002"]
* SearchListExtractorRemoteTest 추가
* 도서관은 303건 초과 리스트를 한꺼번에 요청시에는 자체적으로 검색리스트 데이터를 보내지 않는다. 과거 cgi분석시 maxdisp 인자에 많이 넣을수 있다고 들었던 선입견이 결과 예측에 작용한것 같다. 초기에는 local 서버의 Java JDK쪽에서 자료를 받는 버퍼상의 한계 문제인줄 알았는데, 테스트 작성, Web에서 수작업 테스트 결과 알게 되었다. 관련 클래스 SearchListExtractorRemoteTest )
* Server Refactoring
서버쪽 클래스들에 대해서 Refactoring 을 시도 데이터클래스이면서 그 용도가 조금씩 달랐던 클래스들을 하나로 묶었다. (일단 모여해쳐 시도용으로) 그러면서 안쓰는 클래스들을 조금씩 지워나갔다. 패키지들중 Test 패키지와 메인 소스 패키지, 임시 코드 패키지들에 대해서 화일들을 옮기고 정리했다. 아직 완벽하게 정리된것 같진 않지만, 개인적으로는 이전에 비해 만족스러웠다. (이제 Target은 Resin 쪽과 임시소스들 디렉토리.)
* Code Review 로서 Refactoring 이 이용된다고 했다시피, Refactoring을 해 나가면서 전체 프로그램의 그림이 좀 더 이해가 갔다. 한동안 해당 프로그램에 대해서 플밍 리듬을 놓쳤을때 Refactoring 을 시도하는것도 좋은 전략이라 생각.
* Task 를 작성할때 Refactoring 을 명시적으로 써 놔야 하겠다. Acceptance Test 처럼. 써놓지 않으니까 잊어먹고 자주 안해준 것 같다. 그리고 생각보다 시간이 걸리는 만큼. (이건 Refactoring 을 플밍 중에 자주 해주지 않아서인것 같다. 2시간정도 걸렸으니)
* {{{~cpp ViewBookExtractorTest}}} ( {{{~cpp LendBookList}}} 와 연계하여 테스트 추가 )
* 자칫 RDD 에서의 그 세부클래스들에 대해서 너무 많이 생각하면 BUFD(Big Up-Front Design) 이 되리라 생각한다. 차라리 Class 가 2개였을때 코딩 들어가고, 20-30분 정도 코딩뒤 ["Refactoring"] 을 의식적으로 하여 Big Class 에 대해 Extract Class 를 추구하는게 더 빠르지 않았을까.
1. MVC를 생각하면서, 이에 맞는 JSP(View), Servlet(Controller), Bean(Model)로서의 WebProgramming을 구상하였다.
즉, 앞의 디자인의 경우 JSP 페이지들의 네이밍에 Logic 디자인이 영향을 받았다고 할까. 뭐, 어차피 구현부분은 제대로 생각하지 않은 Conceptual Model 에 가까운 것이였지만, 후자의 경우 데이터 클래스와 그 책임을 맡은 클래스들이 더 명시적으로 드러났던것 같다. 전자의 경우도 '이 기능을 맡은 클래스야' 하면서 Responsibilty 식으로 접근하려고 노력했지만, 후자의 경우가 그 용어면에서 더 추상적이였다. (전자의 경우 그 이름이 시스템을 드러내려고 했다.)
- 데블스캠프2012/넷째날/묻지마Csharp/Mission3/김수경 . . . . 3 matches
using System.ComponentModel;
private System.ComponentModel.IContainer components = null;
this.components = new System.ComponentModel.Container();
- 1002/Journal . . . . 2 matches
추후 ["Refactoring"] & 다른 위키 페이지에 해당 지식 분양용.
* 쌓아나가야 할 부분이 상당히 많아보이는데.. Refactoring 에서의 경험을 어설프게 가로질러본다면. ReFactoring 을 할때 나쁜 클래스들을 그 안에서 계속 고쳐나가는 것 보단, 새 클래스나 메소드들을 중간에 만든뒤, 나쁜 클래스들을 삭제하는게 더 빠른 방법이다. 좋은 습관을 만들어내는 것이 나쁜 습관을 고쳐내려고 하는것보다 최종적으로 볼땐 더 접근하기 쉽지 않을까 하는 생각을 해본다. 나쁜 점이라 생각하는것은, 의식화해서 고치는 것 보단 좋은 습관으로 대체하고 나쁜 습관을 아에 잊어버리게끔 하는것이 더 나은것 같다.
이번에 리팩토링을 하려고 할때 Legacy Code Refactoring 이라고 상정해서 그럴까. Coverage Test를 완벽하게 작성하는 것에 대해 부담감을 느꼈다. 예전에 유용했었던 '아아. 이미 다 되어있어요.~' 를 다시 적용해볼까.
Refactoring Catalog 정독. 왜 리팩토링 책의 절반이 리팩토링의 절차인지에 대해 혼자서 감동중.; 왜 Extract Method 를 할때 '메소드를 새로 만든다' 가 먼저인지. Extract Class 를 할때 '새 클래스를 정의한다'가 먼저인지. (절대로 '소스 일부를 잘라낸다'나 '소스 일부를 comment out 한다' 가 먼저가 아니라는 것.)
ProjectPrometheus Refactoring 궁리하기
Refactoring 을 하기전 Todo 리스트를 정리하는데만 1시간정도를 쓰고 실제 작업을 들어가지 못했다. 왜 오래걸렸을까 생각해보면 Refactoring 을 하기에 충분히 Coverage Test 코드가 없다 라는 점이다. 현재의 UnitTest 85개들은 제대로 돌아가지만, AcceptanceTest 의 경우 함부로 돌릴 수가 없다. 왜냐하면 현재 Release 되어있는 이전 버전에 영향을 끼치기 때문이다. 이 부분을 보면서 왜 JuNe 이 DB 에 대해 세 부분으로 관리가 필요하다고 이야기했는지 깨닫게 되었다. 즉, DB 와 관련하여 개인 UnitTest 를 위한 개발자 컴퓨터 내 로컬 DB, 그리고 Integration Test 를 위한 DB, 그리고 릴리즈 된 제품을 위한 DB 가 필요하다. ("버전업을 위해 기존에 작성한 데이터들을 날립니다" 라고 서비스 업체가 이야기 한다면 얼마나 황당한가.; 버전 패치를 위한, 통합 테스트를 위한 DB 는 따로 필요하다.)
factory method를 사용해라.
Prometheus 코드를 다시 checkout 하고 UnitTest 깨진 부분을 보면서 기존의 TDD 진행 보폭이 얼마나 컸는지가 보였다. (다시 Green Bar 를 보이게끔 하기에 진행해야 할일이 많았으니까. Extractor Remote Test 가 no matched (정규표현식에서 매칭 실패)로 깨졌을때 생각해야 할 일이 두가지이다. 하나는 HTML 이 제대로 받아졌는가(또는 HTML 이 도서관에서의 에러코드를 반환하는가), 하나는 extractor 가 그 구실을 제대로 하는가. 그런데, 테스트 코드를 보면 저 두가지가 묶여있다.
그리고, 도서관 UI 가 바뀌었을 경우에 대한 대처방안에 대해서 이리저리 아이디어를 궁리해 보았었는데, 정규표현식부분을 따로 떼어내어 외부화일로 두던지 (이렇게 하면 컴파일하지 않아도 정규표현식을 수정하면 된다) 또는 HTML 을 전부 Parsing 하여 DOM 트리를 만든뒤 해당 노드의 Position 들에 대해 따로 외부화일로 두던지 (이는 추후 일종의 extractor tool 로 빼낼 수 있을 것이므로) 하는 아이디어가 떠올랐다.
1차적으로 CRC 를 이용하여 간단한 Conceptual Model 을 만든뒤, TDD 로 개개 모듈을 작업했다.
중간 개개의 모듈을 통합할때쯤에 이전에 생각해둔 디자인이 제대로 기억이 나지 않았다.; 이때 Sequence Diagram 을 그리면서 프로그램의 흐름을 천천히 생각했다. 어느정도 진행된 바가 있고, 개발하면서 개개별 모듈에 대한 인터페이스들을 정확히 알고 있었기 때문에, Conceptual Model 보다 더 구체적인 Upfront 로 가도 별 무리가 없다고 판단했다. 내가 만든 모듈을 일종의 Spike Solution 처럼 접근하고, 다시 TDD를 들어가고 하니까 중간 망설임 없이 거의 일사천리로 작업하게 되었다.
아직은 필요한 시스템만 Install 하는 목표에 충실하도록 노력하자. ["Refactoring"]. NoSmok:필요한만큼만 .
혹시 FakeIt & Refactoring 으로 진행이 가능할까 생각해보면서 처음에는 FakeIt & Refactoring 만으로 진행해보았다. 근데, FakeIt 을 하고 ["Refactoring"] 을 하려 할때 너무 재정의를 많이 하는 것 같아서 대강 넘어갔는데, 그랬더니 다음 테스트로 진행하기 너무 힘들었다. 알고리즘이 어느정도 보이려고 할때, 앞에서의 FakeIt 으로 유도된 코드들을 수정하는게 아니라 아에 뜯어야 할 것 같아서 망설여졌다.
* 다양한 경험 - 내용을 만들어내려면, 그만큼 경험이 필요하기에. 성장계단이라던가, 자신이 '배운' 내용을 '적용' 해볼 수 있는 터로서 이용한다던가, ["Refactoring"] 과 프로그래밍 개발의 관점에서 설명한다던가 등등 (이것같은 경우 내용을 알고 있어도, 사람들의 레벨에 맞춰야 하기때문에 적절하게 꺼낼 타이밍을 맞춰야 할것 같은데. 이야기가 흘러가면서 페이지 구조조정, ["Refactoring"] 으로까지의 이야기흐름전개. 어떻게 흘러온걸까.)
* 학교에서 레포트를 쓰기 위해 (["ProgrammingLanguageClass/Report2002_2"]) 도서관에 들렸다. HowToReadIt 의 방법중 다독에 관한 방법을 떠올리면서 약간 비슷한 시도를 해봤다. (오. 방법들 자체가 Extreme~ 해보인다;) 1시간 30분 동안 Java 책 기초서 2권과 원서 1권, VB책 3권정도를 훑어읽었다. (10여권까지는 엄두가 안나서; 도서관이 3시까지밖에 안하는 관계로) 예전에 자바를 하긴 했었지만, 제대로 한 기억은 없다. 처음에는 원서와 고급서처럼 보이는 것을 읽으려니까 머리에 잘 안들어왔다. 그래서 가장 쉬워보이는 기초서 (알기쉬운 Java2, Java2 자바토피아 등 두께 얇은 한서들) 를 읽고선 읽어가니까 가속이 붙어서 읽기 쉬웠다. 3번째쯤 읽어나가니까 Event Listener 의 Delegation 의 의미를 제대로 이해한 것 같고 (예전에는 소스 따라치기만 했었다.) StatePattern으로의 진화 (진화보단 '추후적응' 이 더 맞으려나) 가 용이한 구조일 수 있겠다는 생각을 하게 되었다. (Event Listener 에서 작성했던 코드를 조금만 ["Refactoring"] 하면 바로 StatePattern 으로 적용을 시킬 수 있을 것 같다는 생각이 들었다. 아직 구현해보진 않았기 때문에 뭐라 할말은 아니지만.) 시간이 있었다면 하루종일 시도해보는건데 아쉽게도 학교에 늦게 도착해서;
- Bioinformatics . . . . 2 matches
== NCBI DataModel ==
왜 Model을 이용하는가? 실제에 가까운 모델은 실제로 일어나는 일을 보다 더 잘 이해시키고 예측가능하게 한다.
=== GenBank flatfile & format VS NCBI data model===
- ComputerGraphicsClass/Exam2004_2 . . . . 2 matches
=== Basic Illumination Model ===
=== Modeling Trchniques ===
- ConnectingTheDots . . . . 2 matches
SoftwareDevelopmentMagazine 에 소개된 ModelViewPresenter 관련 구현 예.
Game - Model. 관계는 Presenter 와만 맺는다. 외부에서 이벤트가 발생했을때는 Presenter 를 통해 통지받는다.
- DesignPatterns/2011년스터디/1학기 . . . . 2 matches
1. Factory Method와 Template Method 방법에대해 나쁜점을 설명하는데 Swing이 나오니까 다시 화난다. 난 Swing디자인이 싫어!!
1. Factory Method, Abstract Factory Method, Template Method, Command, Strategy의 비교를 통해 상속구현의 비효율성에 대해 느꼇다.
1. 지난주에 헷갈렸던 Factory Method 패턴에 대해 이해할 수 있게 됐다.
1. Factory Method 패턴은 상속을 통해 바뀌는 부분을 오버라이딩하여 구현
1. '''Model''' : 비즈니스 로직에 필요한 데이터들을 저장하는 클래스군.
1. '''Control''' : Model과 View 사이의 정보 교환을 제어하는 클래스군. 모델군의 데이터를 뷰가 출력하는데 용이하도록, 뷰에서 받은 데이터를 모델에게 적합하도록 가공해준다.
- GuiTesting . . . . 2 matches
대부분의 경우는 TFP를 하는중에 logic 부분과 UI 부분을 분리함으로서 GuiTesting 을 복잡하게 하는 요소들을 줄일 수 있다. 그러면서 Model - View - Controler 의 형태가 유도되어질 것이다.
MVC 는 View 단을 테스트하기에 적합하지 않은 면이 있다. 그래서 ModelViewPresenter 로 해보니 좋았다. --NeoCoin
- OpenGL스터디_실습 코드 . . . . 2 matches
glMatrixMode(GL_MODELVIEW);
glMatrixMode(GL_MODELVIEW);
//glShadeModel(GL_FLAT);
// Reset Model view matrix stack
glMatrixMode(GL_MODELVIEW);
glMatrixMode(GL_MODELVIEW);
- RelationalDatabaseManagementSystem . . . . 2 matches
A relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model as introduced by Edgar F. Codd.
= Relational Model =
The fundamental assumption of the relational model is that all data are represented as mathematical relations, i.e., a subset of the Cartesian product of n sets. In the mathematical model, reasoning about such data is done in two-valued predicate logic (that is, without NULLs), meaning there are two possible evaluations for each proposition: either true or false. Data are operated upon by means of a relational calculus and algebra.
The relational data model permits the designer to create a consistent logical model of information, to be refined through database normalization. The access plans and other implementation and operation details are handled by the DBMS engine, and should not be reflected in the logical model. This contrasts with common practice for SQL DBMSs in which performance tuning often requires changes to the logical model.
The basic principle of the relational model is the Information Principle: all information is represented by data values in relations. Thus, the relvars are not related to each other at design time: rather, designers use the same domain in several relvars, and if one attribute is dependent on another, this dependency is enforced through referential integrity.
에드가 코드는 IBM에서 일할 당시 하드 디스크 시스템의 개발을 하였다. 이 사람은 기존의 codasyl approach 의 navigational 모델에 상당히 불만을 많이 가지고 있었다. 왜냐하면 navigational 모델에서는 테이프 대신에 디스크에 데이터베이스가 저장되면서 급속하게 필요하게된 검색 기능에 대한 고려가 전혀되어있지 않았기 때문이다. 1970년에 들어서면서 이 사람은 데이터베이스 구축에 관한 많은 논문을 썻다. 그 논문은 결국에는 A Relational Model of Data for Large Shared Data Banks 라는 데이터 베이스 이론에 근복적인 접근을 바꾸는 논문으로 집대성되었다.
- SoftwareEngineeringClass/Exam2002_1 . . . . 2 matches
1. Sprial Model 의 특징에 대해 서술하시오.
문제 달랑 3개라는 것도 알고 있었고, Sprial Model 은 나올줄 알고 있었건만. 우.. 복병을 만나다;
- SolarSystem/상협 . . . . 2 matches
glMatrixMode(GL_MODELVIEW); // Select The Modelview Matrix
glShadeModel(GL_SMOOTH);
- UML/CaseTool . . . . 2 matches
''Diagramming'' in this context means ''creating'' and ''editing'' UML [[diagram]]s; that is diagrams that follow the graphical notation of the Unified Modeling Language.
The diagramming part of the Unified Modeling Language seems to be a lesser debated part of the UML, compared to code generation.
''[[Code generation]]'' in this context means, that the user creates UML diagrams, which have some connoted model data, from which the UML tool derives (through a conversion process) parts or all of the [[source code]] for the software system that is to be developed. Often, the user can provide some skeleton of the program source code, in the form of a source code [[template]] where predefined tokens are then replaced with program source code parts, emitted by the UML tool during the code generation process.
''Reverse engineering'' in this context means, that the UML tool reads program source code as input and ''derives'' model data and corresponding graphical UML diagrams from it (as opposed to the somewhat broader meaning described in the article "[[Reverse engineering]]").
There are UML tools that use the attribute ''round trip'' (sometimes also denoted as ''round trip engineering'') to connote their ability to keep the ''source code'', the ''model data'' and the corresponding ''UML diagrams'' ''in sync''.
This means that the user should be able to change either the ''model data'' (together with the corresponding diagrams) or the ''program source code'' and then the UML tool updates the other part automatically.
- ZIM . . . . 2 matches
* ["ZIM/ConceptualModel"] - (by 시스템 아키텍트)
''예. 맞습니다. ["ZIM/ConceptualModel"] 의 Zimmer에 대한 정의를 비워놨었었군요.''
- django . . . . 2 matches
* [http://www.mercurytide.com/knowledge/white-papers/django-full-text-search] : Model 의 Object 에 대한 함수들 사용방법
* [django/Model]
- django/ModifyingObject . . . . 2 matches
class Employee(models.Model):
name= models.CharField(maxlength=100)
email= models.EmailField()
데이터베이스에서 레코드를 삭제하는 작업은 Model클래스의 delete메소드로 추상화했다. 하지만 내부에서 실제로 레코드를 삭제하는 메소드는 delete_objects이다.[8] delete_objects메소드는 지우려는 레코드를 참조하는 다른 테이블의 레코드까지 함께 삭제하거나, 외래키를 NULL값으로 설정한다. 예를 들어 다음은 Risk테이블에서 한 레코드를 삭제하는 경우 이를 참조하는 Consequence, Control 테이블의 레코드까지 함께 삭제하는지를 묻는 사용자 화면이다.
- 정모/2011.5.23 . . . . 2 matches
* 휴면회원 [김홍기]의 [wiki:SibichiSeminar/TrustModel 이 사람이 휴면회원인 이유]
* 먼저 자바스크립트 스터디에 관심이 생겼어요(진경이도 어제 뭐더라.. 어떤 언어가 알고리듬이 아주 달라서 배울만한 가치가 있다고 하더라구요. 같은 맥락이지 싶어요). 내일 몇시인지 알아낸 다음에 어떻게 진행되고 있는지 살펴보고, 적합하다 판단되면 저도 동참해야겠어요. 또 세미나를 보면서, 와.. 저런걸 여기서도 구현하는구나.. 라는 생각이 들었어요. TrustModel과 비슷한걸 만들고자 하는 사람들을 아는데, 저런식으로 아예 수치화 시키는게 역시 효율적인가.. 라는 생각도 들었구요, 후에 연구실(다른데인가?)에 들어간다면 저런걸 하는걸 보게/혹은 후에는 직접 하게될 수 있다는 사실에 나름 다시 감탄(?)했어요. ..아니면 빨리 이 길을 뜨는게 답인가요?ㅋㅋㅋㅋ 아, 또 성현이형이 동아리에서 프로젝트같은거 하신다고 하셨는데, 어떤걸 누구와 어떻게하였는지(그러니까 그 전반)도 한번 들어볼 기회가 있으면 좋겠어요. 여기서 잘 복붙해서 세미나 글에도 후기를 올려야겠네요...ㅎㅎ -[김태진]
- 졸업논문/참고문헌 . . . . 2 matches
[6] "Model reference", http://www.djangoproject.com/documentation/model_api/
[8] http://code.djangoproject.com/browser/django/trunk/django/db/models/query.py
[9] "Or lookups", http://www.djangoproject.com/documentation/models/or_lookups/
[11] "A Relational Model of Data for Large Shared Data Banks", E. F. Codd , Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387.
- AM . . . . 1 match
* [AM]이라는 약어를 보면 AgileModeling 이 떠오르는군요..; - [임인택]
- ActiveTemplateLibrary . . . . 1 match
{{|The Active Template Library (ATL) is a set of template-based C++ classes that simplify the programming of Component Object Model (COM) objects. The COM support in Visual C++ allows developers to easily create a variety of COM objects, Automation servers, and ActiveX controls.
- Adapter . . . . 1 match
상호 작용(사용자가 직접 이용하는의미)하는 어플리케이션을 위한 Model-View-Controller(MVC) 패러다임에서 View 객체들(화면상에 표현을 담당하는 widget들) 은 밑바탕에 깔려있는 어플리케이션 모델과 연결되어진다. 그래서 모델안에서의 변화는 유저 인터페이스에 반영하고 인터페이스 상에서 사용자들에 의한 변화는 밑에 위치한 되어지는 모델 데이터(moel data)에 변화를 유도한다.View객제들이 제공되어 있는 상태라서 어떠한 상호 작용하는 어플리케이션 상에서라도 그들은 ㅡ걸 사용할수 있다. 그러므로 그들은 그들의 모델과의 통신을 위해 일반적인 프로코콜을 사용한다;특별한 상황에서 모델로 보내어지는 getter message는 값이고 일반적인 setter message역시 값이다.:예를 들자면 다음 예제는 VisualWorks TextEditorView가 그것의 contects를 얻는 방법이다.
t := model valud
- Ajax . . . . 1 match
* The Document Object Model manipulated through JavaScript to dynamically display and interact with the information presented
- Barracuda . . . . 1 match
Presentation Frameworks로 Model 2형태의 Architecture 를 구현한다.
- COM . . . . 1 match
#Redirect ComponentObjectModel
- ComponentObjectModel . . . . 1 match
{{|Component Object Model, or COM, is a Microsoft technology for software componentry. It is used to enable cross-software communication and dynamic object creation in many of Microsoft's programming languages. Although it has been implemented on several platforms, it is primarily used with Microsoft Windows. COM is expected to be replaced to at least some extent by the Microsoft .NET framework. COM has been around since 1993 - however, Microsoft only really started emphasizing the name around 1997.
- C언어시험 . . . . 1 match
수업시간에 시험에 나온 Waterfall, Spiral Model등등 프로세스에 관한 측면과 소프트웨어 디자인에 대한 강의도 있었다고 하는데 제 느낌이지만 교수님께서 너무 앞서나가셔서 (리듬이 맞지 않았다고 하면 될 것 같네요) 학생들이 받아들이는데 문제가 있었던것 같습니다. (이러한 주제를 다룬것 자체에 대해서는 학생들이 그다지 크게 잘못된 생각을 가지고 있는것 같지는 않습니다) 제가 수업을 들었었다면 조금 더 구체적으로 적을수 있었을텐데 아쉽네요. 적적한 메타포의 활용이 아쉽네요. 저는 요새 후배들에게 무언가를 가르치려고 할때 메타포를 많이 활용하고자 한답니다. - [임인택] - 추가해서. 제가 사실을 잘못 알고 있으면 누가 말씀해 주시길 바랍니다.
- DOM . . . . 1 match
#redirect DocumentObjectModel
- DocumentObjectModel . . . . 1 match
Document Object Model (DOM) is an application programming interface to access HTML and XML documents. It is programming language and platform independent. Behind the interface the document is represented with an object-oriented model.
Most XML parsers (e.g., Xerces) and XSL processors (e.g., Xalan) have been developed to make use of the tree structure. Such an implementation requires that the entire content of a document be parsed and stored in memory. Hence, DOM is best used for applications where the document elements have to be randomly accessed and manipulated. For XML-based applications which involve a one-time selective read/write per parse, DOM presents a considerable overhead on memory. The SAX model is advantageous in such a case in terms of speed and memory consumption.
- EnglishSpeaking/2011년스터디 . . . . 1 match
* Theme : 자신의 ''Role Model''.
- Gof/FactoryMethod . . . . 1 match
= Factory Method =
Factory Method는 sub 클래스에 대해 구현 사항을 결정할수 있게 만든다.
Factory Method 패턴은 이에 대한 해결책을 제시한다. 그것은 Document의 sub 클래스의 생성에 대한 정보를 캡슐화 시키고, Framework의 외부로 이런 정보를 이동 시키게 한다.
* Factory Method가 생성하는 객체에 관한 인터페이스를 정의한다.
* Procunt 형의 객체를 반환하는 Factory Method를 선언한다. Creator는 또한 기본 ConcreteProduct객체를 반환하는 factory method에 관한 기본 구현도 정의되어 있다.
* Product객체를 만들기위한 factory method를 호출한다.
* ConcreteProduct의 인스턴스를 반환하기 위한, factory method를 오버라이드(over ride) 한다.
Creator는 factor method가 정의되어 있는 Creator의 sub클래스에게 의지한다 그래서 Creator는 CooncreteProduct에 적합한 인스턴스들을 반환한다.
Factory method는 당신의 코드에서 만들어야한 Application이 요구하는 클래스에 대한 기능과 Framework가 묶여야할 필요성을 제거한다. 그 코드는 오직 Product의 인터페이스 만을 정의한다.; 그래서 어떠한 ConcreteProduct의 클래스라도 정의할수 있게 하여 준다.
factory method의 잠재적인 단점이라고 한다면 클라이언트가 아마도 단지 특별한 ConcreteProduct객체를 만들기위해서 Creator클래스의 sub클래스를 가지고 있어야 한다는 것일꺼다. 클라이언트가 어떤 식으로든 Creator의 sub클래스를 만들때의, sub클래스를 만드는 것자체는 좋다. 하지만 클라이언트는 이런것에 신경쓸 필요없이 로직 구현에 신경을 써야 한다.
A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object. Subclassing is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution.
자, 역시 Factory Method 패턴에 관련한 두가지의 결론을 이야기 한다.:
Here are two additional consequences of the Factory Method pattern:
1. ''서브 클래스와 소통 통로 제공''(''Provides hooks for subclasses.'') Factory Method를 적용한 클래스에서 객체의 생성은 항상 직접 만들어지는 객체에 비하여 유연하다. Factory Method는 객체의 상속된 버전의 제공을 위하여, sub클래스와 연결될수 있다.(hook의 의미인데, 연결로 해석했고, 그림을 보고 이해해야 한다.)
Ducument에제에서 Document클래스는 factory method에 해당하는, 자료를 열람하기 위한 기본 파일 다이얼로그를 생성하는 CreateFileDialog이 호출을 정의할수 있다. 그리고 Document sub클래스는 이러한 factory method를 오버 라이딩해서 만들고자 하는 application에 특화된 파일 다이얼로그를 정의할수 있다. 이러한 경우에 factory method는 추상적이지 않다. 하지만 올바른 기본 구현을 제공한다.
2. ''클래스 상속 관게에 수평적인(병렬적인) 연결 제공''(''Connects parallel class hierarchies.'') 여태까지 factory method는 오직 Creator에서만 불리는걸 생각해 왔다. 그렇지만 이번에는 그러한 경우를 따지는 것이 아니다.; 클라이언트는 수평적(병렬적)인 클래스간 상속 관계에서 factory method의 유용함을 찾을수 있다.
Figure클래스는 CreateManipulator라는, 서로 작용하는 객체를 생성해 주는 factory method이다. Figure의 sub클래스는 이 메소드를 오버라이드(override)해서 그들에게 알맞는 Manipulator sub클래스의 인스턴스를 (만들어, )반환한다. Figure 클래스는 아마도 기본 Manipulator인스턴스를 (만들어,) 반한하기 위한 기본 CreateManipulator를 구현했을 것이다. 그리고 Figure의 sub클래스는 간단히 이러한 기본값들을 상속하였다. Figure클래스 들은 자신과 관계없는 Manipulator들에 대하여 신경 쓸필요가 없다. 그러므로 이들의 관계는 병렬적이 된다.
Factory Method가 두게의 클래스의 상속 관계에서 어떻게 이러한 연결과정을 정의하는지 주목하라. 그것은 서로 고유의 기능을 부여시키는 작업을 한다.
Factory Method패턴이 적용될때 발생할수 있는 문제에 관해서 생각해 보자.:
1. 두가지의 커다란 변수. Factory Method 패턴에서 두가지의 중요한 변수는 '''첫번째''' Creator 클래스가 가상 클래스이고, 그것의 선언을 하지만 구현이 안될때의 경이 '''두번째'''로 Creator가 concrete 클래스이고, factor method를 위한 기본 구현을 제공해야 하는 경우. 기본 구현이 정의되어 있는 가상 클래스를 가지는건 가능하지만 이건 일반적이지 못하다.
- HowToStudyXp . . . . 1 match
* ["Refactoring"] (by Martin Fowler) : 리팩토링에 대한 최고의 책
* http://groups.yahoo.com/group/refactoring
'''Agile Modeling''' by Scott W. Ambler
- LearningGuideToDesignPatterns . . . . 1 match
Pattern들은 각각 독립적으로 쓰이는 경우는 흔치 않다. 예를 들면, IteratorPattern은 종종 CompositePattern 과 같이 쓰이고, ObserverPattern과 MediatorPattern들은 전통적인 결합관계를 형성하며, SingletonPattern은 AbstractFactoryPattern와 같이 쓰인다. Pattern들로 디자인과 프로그래밍을 시작하려고 할때에, 패턴을 사용하는데 있어서 실제적인 기술은 어떻게 각 패턴들을 조합해야 할 것인가에 대해 아는 것임을 발견하게 될 것이다.
=== Factory Method - Creational ===
FactoryMethodPattern 로 시작하라. 이 패턴은 다른 패턴들에 전반적으로 사용된다.
앞에서의 IteratorPattern 의 예제코드에서의 "Traverse" 는 TemplateMethodPattern 의 예이다. 이 패턴은 StrategyPattern 과 FactoryMethodPattern 를 보충해준다.
=== Abstract Factory - Creational ===
AbstractFactoryPattern은 두번째로 쉬운 creational Pattern이다. 이 패턴은 또한 FactoryMethodPattern를 보강하는데 도움을 준다.
AbstractFactoryPattern 과 BuilderPattern 을 비교해보라.
SingletonPattern은 종종 AbstractFactoryPattern 을 만드는데 이용된다. (Related Patterns 참조)
ObserverPattern 과 Model-View-Controller (MVC) Design 을 이해하기 위한 준비단계로 MediatorPattern을 공부한다.
- MFC/ObjectLinkingEmbedding . . . . 1 match
OLE 컨테이너, 서버 사이의 통신은 윈도우 운영체제를 매개로 동작한다. 각 OLE 를 지원하는 프로그램은 공통의 OLE DLL을 가지는데 이 것이 윈도우의 기본지원 부분이다. DLL 안의 함수들은 이렇게 객체사이의 통신을 지원한다. 이때 이를 지원하는 표준적인 인터페이스가 COM(Component Object Model)이다. 본질적으로 엠비드된 객체의 모양과 컨테이너가 그것과 통신하는 방법을 정의한것이다.
- MoreMFC . . . . 1 match
http://www.zeropage.org/~erunc0/study/mfc/WModel.gif
- NotToolsButConcepts . . . . 1 match
[1002] 가 Windows Programming 을 오래 하다가 EventDrivenProgramming 의 개념을 나름대로 제대로 받아들였다는 느낌이 들었을때는 해당 플랫폼에서 1년 이상 작업했을 때 였다.(여기서 '받아들였다'는 실제 EventDriven Model로 디자인해서 구현해보는 정도) 사람들의 공부 스타일에 따라 차이가 있지만, 해당 개념에 대해 제대로 이해하기 위해선 구현레벨에서의 경험도 필요하다. 위의 '예' 에서 '아닌 - Not' 이란 단어대신 '넘어서 - Beyond' 라는 단어로 바꿔서 읽어보면 어떨까.
- PairSynchronization . . . . 1 match
NoSmok:PairDrawing 이 있긴 한데, 여기서는 개발자들끼리의 대화이므로 다른것을 써도 좋겠네요. PairModeling? --["1002"]
- PatternOrientedSoftwareArchitecture . . . . 1 match
|| Interactive Systems || Model-View-Controlled, Presentation-Abstraction-Control Pattern || - ||
- ProjectZephyrus/Afterwords . . . . 1 match
- PairProgramming 전에 진행 전략을 세웠다. (5분 PP 라던지, PP 순서시 간단한 Modeling 뒤, Sequence Diagram 등을 그리고 난 뒤 진행을 한다던지, 후배들에게 프로그래밍이 완성되었을 경우에 어떠어떠하게 돌아갈 것이다 라고 미리 그 결과를 생각해보게끔 유도)
- SibichiSeminar . . . . 1 match
* [SibichiSeminar/TrustModel]
- SingletonPattern . . . . 1 match
이전에 ProjectZephyrus 를 프로그래밍할때 느낀점이라면, 초반에 디자인을 할 때 일수록 Singleton 을 쓸 생각을 하지 않는것이 좋겠다는 점이다. 초반에 디자인을 할때엔 (특히 Conceptual Model 단계정도만 생각하고 프로그래밍에 들어가는 사람의 경우) 어떠한 클래스건 대부분이 인스턴스가 한개이다. -_- 그렇다고 이 모든 것들을 글로벌 객체로 만들어내는 것은 그리 좋지 않다. --["1002"]
- Spring/탐험스터디/wiki만들기 . . . . 1 match
public String write(@RequestParam("title") String title, @RequestParam("contents") String contents, Model model, Principal principal) {
- TCP/IP 네트워크 관리 / TCP/IP의 개요 . . . . 1 match
*ISO(International Standards Organization, 국제 표준기구)에 의해 개발된 구조적 모델 '''OSI'''(Open Systems Interconnect Reference Model)은 데이터 통신 프로토콜 구조와 기능 설명을 위해 자주 사용.
- TddWithWebPresentation . . . . 1 match
그러다가, 최근 프로젝트 하는중에 ModelViewPresenter 라는 개념에 대해 익히게 되었다. 정확한 개념에 대해서는 잘 잡지를 못했지만, HumbleDialogBox 라는 아티클을 보니 대강 감이 온것 같았다. 중요한 건 표현부분에 대해서 가능한한 로직이 남지 않아야 한다는 점이고, 표현부분을 사용하는 쪽 입장에서도 가능한한 추상화레벨이 높은 메소드를 쓸 수 있어야 한다는 점이다.
- ZeroPage_200_OK . . . . 1 match
* Browser Object Model : 자바스크립트로 Browser와 상호작용하기 위해 제공되는 API들의 집합. 공식적인 표준은 존재하지 않아서 조금씩 다를 수 있다.
- django/Example . . . . 1 match
[django/Model]
- django/RetrievingObject . . . . 1 match
데이터베이스에서 레코드를 조회할 때는 Model클래스를 관리하는 Manager클래스를 이용한다. 가장 간단하게는 모든 레코드를 가져오는 방법이 있는데, 모델마다 기본적으로 제공되는 object라는 매니저를 이용한다. object 매니저로 레코드를 조회하면 QuerySet이 반환된다. 이는 관계형 데이터베이스 CLI인 JDBC의 ResultSet과 유사하다.
- erunc0/Java . . . . 1 match
* ["MVCModel"]
- geniumin . . . . 1 match
== Conceptual Model of Geniumin.. ==
- 김동준/Project/OOP_Preview/Chapter1 . . . . 1 match
private String model;
this.model = null;
GuitarProperty(String SN, double price, String builder, String model, String type,
this.model = model;
public String getModel() { return this.model; }
- 논문번역/2012년스터디/서민관 . . . . 1 match
이 논문에서는 어휘 제한이 없는 off-line의 필기 인식을 기본으로 한 Hidden-Markov-Model을 소개할 것이다.
축척 인자(scaling factor)는 선형적으로 이 관계에 기반한다. 이는 이 관계가 클수록 필기 스타일이 좁아지기 때문이다.
- 데블스캠프2012/넷째날/묻지마Csharp/Mission3/김준석 . . . . 1 match
using System.ComponentModel;
- 데블스캠프2012/넷째날/묻지마Csharp/김태진 . . . . 1 match
using System.ComponentModel;
- 수업평가 . . . . 1 match
||ObjectModelingClass || . || . || . || . || . || . ||. ||
- 정모/2012.7.25 . . . . 1 match
* MVC의 Model과 DDD(는 아니지만)의 Domain - Repository와의 관계에 대해 고민했다. DAO와 Repository의 차이가 무엇인지 아직 잘 모르겠다. - [서지혜]
- 프로그램내에서의주석 . . . . 1 match
아..["Refactoring"] 하라는 거군요.. 사실 설계 자체에서도 빠진 상태라 전체 구조 이해하는데 가장 크게 애를 먹었습니다. 아무튼 진짜 이해한 후에 코드를 수정해 놓는 것도 좋은 방법인건 분명하다고 생각합니다. ^^; --창섭
하지만, "확실히 설명할때 {{{~cpp JavaDoc}}}뽑아서 그거가지고 설명하는게 편하긴 편하더라."라고 한말 풀어쓰는 건데, 만약 디자인 이해 후에 코드의 이해라면 {{{~cpp JavaDoc}}} 없고 소스만으로 이해는 너무 어렵다.(최소한 나에게는 그랬다.) 일단 코드 분석시 {{{~cpp JavaDoc}}}이 나올 정도라면, "긴장 완화"의 효과로 먹고 들어 간다. 그리고 우리가 코드를 읽는 시점은 jdk를 쓸때 {{{~cpp JavaDoc}}}을 보지 소스를 보지는 않는 것처럼, 해당 메소드가 library처럼 느껴지지 않을까? 그것이 메소드의 이름이나 필드의 이름만으로 완벽한 표현은 불가능하다고 생각한다. 완벽히 표현했다면 너무나 심한 세분화가 아닐까? 전에 정말 난해한 소스를 분석한 적이 있다. 그때도 가끔 보이는 실낱같은 주석들이 너무나 도움이 된것이 기억난다. 우리가 제출한 Report를 대학원 생들이 분석할때 역시 마찬가지 일것이다. 이건 궁극의 Refactoring문제가 아니다. 프로그래밍 언어가 그 셰익스피어 언어와 같았으면 하기도 하는 생각을 해본다. 생각의 언어를 프로그래밍 언어 대입할수만 있다면야.. --["상민"]
내가 Comment 와 JavaDoc 둘을 비슷한 대상으로 두고 쓴게 잘못인듯 하다. 두개는 좀 구분할 필요가 있을 것 같다는 생각이 들어서다. 내부 코드 알고리즘 진행을 설명하기 위해서는 다는 주석을 comment로, 해당 구성 클래스들의 interface를 서술하는것을 JavaDoc으로 구분하려나. 이 경우라면 JavaDoc 과 Class Diagram 이 거의 비슷한 역할을 하겠지. (Class Diagram 이 그냥 Conceptual Model 정도라면 또 이야기가 달라지겠지만)
- 학회간교류 . . . . 1 match
* CMMI (Capability Maturity Model Integration)
- 환경의중요성 . . . . 1 match
제로페이지는 훌륭한 공동체이다. 그들은 끊임없이 배우려고 하고 새로운 문화를 창출해 내려 한다. 단지 아쉬운건 그들에게 필요한 환경이 부족하다는 것이다. (TomDeMarco 가 PeopleWare에서 언급한 모델이나 AgileModeling에 언급되는 CavesAndCommon과 같은 장소적 측면에서의 환경) - [임인택]
- 황재선 . . . . 1 match
jtable.getColumnModel().getColumn(index).setPreferredWidth(size);
Found 73 matching pages out of 7540 total pages (5000 pages are searched)
You can also click here to search title.
